This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

There are only two implementations of the OCI protocol that have been widely battle-tested across the bazillion OCI registries in the world:

https://github.com/containerd/containerd
https://github.com/containers/image

and everything that wraps these like docker, podman, skopeo, k8s, etc.

The protocol is highly ossified, hard to test many of these incantations as they are in private data-centre's we cannot access. Using oci-client crate is a mistake. I propose a little bit of golang just for this transport component.

containerd as a library gets the nod in this PR because it's a CNCF graduated project, it's the default runtime under most Kubernetes distributions (GKE, EKS, AKS), it sits inside Docker Engine, and its image-handling code paths (the remotes resolver and the newer transfer service) are exercised billions of times a day.

containerd also supports Windows, Linux, macOS. Last I tried "containers/image" it isn't buildable or functioning on Windows.

Thanks for expanding on the motivation here. I agree that registry compatibility
is difficult to reproduce comprehensively and that using a widely exercised
implementation such as containerd's registry and archive libraries may be more
robust than maintaining registry resolution and layer semantics ourselves. I
also understand that this proposal links those libraries through a Go
C-shared-library shim; it does not introduce a running containerd daemon.

At the same time, I do not see a concrete registry failure or required use case
in the PR that justifies replacing the current implementation. Before taking on
the additional Go/cgo, unsafe FFI, dynamic-loading, cross-compilation, and
packaging complexity, I think we should identify the incompatibility we are
solving, the registries or OCI behaviours we need to support, and the level of
compatibility expected from the VM driver. If the VM driver's intended scope is
primarily local and experimental, its requirements may differ from those of the
Docker, Podman, or Kubernetes drivers. Issue #2332
now tracks documenting those use cases and limitations, and that positioning
should inform this trade-off.

Before replacing the current implementation, however, I would prefer that we
first reorganise the VM driver's rootfs handling around explicit interfaces.
This reorganisation is also motivated by PR #2312,
which needs the same image-acquisition capabilities but produces an OCI rootfs
artifact rather than a VM disk. Establishing the boundary first would let both
proposals build on the same model instead of introducing separate image
pipelines.

The current code combines several distinct responsibilities inside the VM
driver:

• Image reference resolution and authentication
• Manifest and platform selection
• Blob acquisition and verification
• OCI layout construction
• Layer unpacking and application
• Cache identity and progress reporting
• VM-specific rootfs preparation and ext4 materialisation

PR #2313 changes several of these responsibilities at once while they remain
embedded in the VM driver. It also adds a Go toolchain, cgo shared library,
runtime dynamic loading, embedded artifacts, and a separate dependency and SBOM
surface. Those choices may be justified, but they would be easier to evaluate,
test, replace, and potentially reuse if the architectural boundary existed
first.

Conceptually, I would like the VM rootfs pipeline to look more like:

VmRootfsProvider
├── ImageSource
│   ├── OciClientImageSource          (current)
│   └── ContainerdShimImageSource    (proposed)
├── ImageUnpacker
│   ├── RustLayerUnpacker           (current host path)
│   ├── UmociGuestUnpacker          (current guest path)
│   └── ContainerdArchiveUnpacker   (proposed host path)
└── VmRootfsMaterializer
    └── prepared ext4 image / image-preparation VM

The exact interface names are less important than keeping image acquisition and
OCI-correct unpacking separate from the VM-specific output format. For example,
an ImageSource could produce a verified OCI image layout, an ImageUnpacker
could produce an unpacked rootfs directory, and VmRootfsMaterializer could
turn that directory into the ext4 artifact consumed by libkrun.

The existing umoci dependency is relevant here as well. PR #2313 does not
replace it: the VM image-preparation guest continues to run umoci raw unpack
for OCI-layout payloads, while the new shim adds containerd's archive
implementation for host-side unpacking. OpenShell would therefore manage two
OCI unpack implementations, in addition to the registry acquisition path. That
is not necessarily wrong—the bootstrap rootfs and the need to preserve Linux
filesystem semantics may require different host and guest paths—but the reason
for each dependency and the boundary between them should be explicit. We should
decide whether the shim is intended only for acquisition, whether unpacking can
be consolidated in the preparation guest, or whether separate host and guest
unpackers are an intentional supported design.

We should also evaluate whether more of the acquisition and unpacking path can
run inside the Linux image-preparation guest. That could keep Linux-specific OCI
tooling out of the host process and avoid a host-side cgo/FFI boundary, while
still allowing the guest to use a mature implementation. It may have trade-offs
around networking, credentials, caching, and bootstrap size, but I would like to
see it compared explicitly with the proposed host-loaded shared library.

If we confirm compatibility gaps in the current Rust implementation and decide
that a Go shim is not an approach we want to maintain, another option is to
contribute the missing behaviour and regression tests to the relevant upstream
Rust project. That would preserve a native Rust integration, address the
specific compatibility problems we can demonstrate, and benefit other
Rust-based projects that need the same OCI functionality. The feasibility of
that path depends on the nature of the gaps and the upstream project's scope and
maintainer engagement, but it should be evaluated before introducing a
permanent FFI boundary.

This separation is also relevant to PR #2312.
The proposed OCI provisioner needs image acquisition and rootfs construction,
but its final artifact is an OCI mount or directory tree rather than a VM disk.
If we establish the source and unpacking contracts first, the containerd library
shim proposed here could potentially be reused by both provisioners without
making either one depend on the other's final rootfs representation. It would
also make the daemon-backed provider in #2312 clearly replaceable rather than
allowing containerd daemon concepts to become part of the compute-driver
contract.

I therefore suggest staging this work as follows:

1. Define the VM driver's intended image-compatibility requirements and document
   the concrete failures or unsupported workflows motivating this replacement.
2. Compare the host-loaded Go shim with alternatives, including retaining the
   current implementation, contributing confirmed compatibility fixes and tests
   to an upstream Rust implementation, and moving mature image tooling into the
   preparation guest.
3. Extract the existing VM image source, unpacking, caching, progress, and ext4
   materialisation boundaries without changing behaviour.
4. Keep the current oci-client and Rust unpacker as the initial implementations
   and preserve the existing tests around the new contracts.
5. Introduce the containerd Go shim as alternative ImageSource and
   ImageUnpacker implementations.
6. Compare behaviour, packaging, cross-platform support, security, build
   complexity, overlap with the existing umoci path, and SBOM/licensing
   implications before removing the existing implementation.
7. Decide whether the selected source and unpacker should be shared with the OCI
   provisioner from feat(driver-native): add native compute driver #2312.

My request is not to retain the existing OCI implementation indefinitely. It is
to establish the provider and materialisation boundaries before replacing it,
so this PR becomes a focused implementation change rather than simultaneously
changing the architecture, build system, dependency model, and registry
behaviour. I would prefer that reorganisation to land first, followed by a
smaller version of this PR built against those interfaces.

Agreed the boundary should exist eventually. I'll open a follow-up issue to extract ImageSource/ImageUnpacker once #2312 lands, so the interface is designed against two real implementations rather than speculatively. In the meantime, I've documented why umoci and the containerd archive unpacker coexist (host vs. guest trust boundary) so that's no longer an open question in this PR.